C 端产品夭折早,B 端产品童工多(一)

摘 要

  C 端产品夭折早,B 端产品童工多(一) 编辑导读:C 端产品竞争激烈,绝大部分产品还没等市场验证就夭折了;而 B 端产品大多以定制为主,很难成长为通用型产品,是长不大的 " 童工

C 端产品夭折早,B 端产品童工多(一)

编辑导读:C 端产品竞争激烈,绝大部分产品还没等市场验证就夭折了;而 B 端产品大多以定制为主,很难成长为通用型产品,是长不大的 " 童工 "。B 端产品如何才能跨越通用性和商业化的门槛,长大成人呢?本文作者对此展开分析,与你分享。

C 端产品一将功成万骨枯,绝大部分产品早早夭折。B 端产品定制严重,畸形较多,大部分成为长不大的童工。

C 端用户需要精准琢磨群体心理,通过深厚的感知力去猜测用户的喜好和习惯,很多产品压根洞察不到用户的习惯或者是不能快速获得用户增长,产品很快就面临失败,退出战场,绝大部分产品都是陪葬品,侥幸活下来的产品还要进行残酷的排他性竞争,一将功成万骨枯。

无论是敏捷的创业公司还是实力雄厚的大厂都逃不过这个诅咒,比如腾讯新产品研发时,都是同时开工内部赛马,微信也是从几 10 款 IM 产品中脱颖而出的;字节西瓜、抖音、火山等一连试水 10 几个视频产品,最终抖音只有胜出,都是这个逻辑,成千上万个产品最后只有 1-2 个产品胜出存活,其他产品都早早夭折。

而 B 端产品不一样,B 端产品往往场景和需求明确,不明确的场景还可以反复找用户沟通,直到完美解决用户问题;所以很多 B 端产品就算不成功,在企业内部缝缝补补还是可以用个 3-5 年不成问题;

但是如果想要将其放到市场上运作,立马发现各种各样的问题,就像一个小孩进入到了复杂的社会,完全应对不了各种复杂场景,在企业内部做童工还能勉强使用,想要到外界长大成人,非得经历一番脱胎换骨不可,但是大部分产品都不能跨过这个槛,只有极少数的产品能够跨越通用性和商业化的门槛,长大成人,所以 B 端产品多童工。

一、B 端产品备孕期:有妈有爸,孕育容易

B 端产品备孕期相对比较容易,为什么容易呢?我们将从以下 3 个方面进行论证:

1. B 端开局容易切中企业的真实痛点,解决部分种子用户实际问题

B 端产品的孕育,之前说过主要受到两个东西影响:新的技术革新和新的管理理念,这个是 B 端产品生命的灵魂。通常是老板或者创业者发现企业的生产环境和管理环境中存在某个问题,希望通过新的技术革新和新的管理理念来更好的解决这个问题。

创业者和公司老板其实都面临一个确定的场景,很容易找到几个付费的种子用户来做实验,内部孵化产品的话就以自己公司作为实验田。产品解决的问题明确,使用场景明确,又能够找到明确的用户详细沟通需求,所以对于产品的研发成本和产品的价值很容易算出产品的投入产出比。只要投入产出比还合适,能够解决企业问题,那么就开始投入研发。所以 B 端产品很容易在内部立项启动起来,因为研发出来即使产品不能获得空前成功,也是能够实际解决企业问题的。比如给大家安利两个故事:

1)钉钉源于与一家小企业的共创,驻场开发出 1.0 版本,然后逐步壮大

2014 年阿里巴巴推出的社交产品 " 来往 " 折戟沉沙,来往团队产品负责人陈航(花名无招)不甘心失败,团队搬到阿里巴巴的福源之地 - 湖畔花园,基于已有的 IM 底层技术开始尝试基于工作场景的企业社交产品研发。

2014 年的夏天,他们在一天之内拜访了好几家公司,收获甚微,没人能清晰地表达,需要怎样的一款企业通讯产品。他们又累又失望,找了个杭州的街边店吃臭豆腐,团队成员钟兴德(花名一岱)突然提到,朋友的公司就在楼上,不如上去看看。康帕斯 80 多人,主营电脑硬件销售,是典型的中小企业代表。康帕斯 CEO 史楠吐槽了一大堆工作上的痛点,他非常头痛的是,微信、QQ 还有短信等等,把工作和生活混在一起,难以形成工作的专注。

陈航答应他,免费为他做出一款专门用于工作沟通协同的产品,让他用到 " 爽 " 为止。后面【钉钉】团队的产品和研发人员几乎驻场到康帕斯,根据企业提出的明确的诉求进行钉钉 1.0 版本的研发,企业有什么问题立即做出相应的解决对策,和客户一起,深度绑定,一起上班下班,通过观察甚至亲身体验,熟悉客户企业的工作流程,切实感受他们的需求和痛点,再来设计和改进钉钉的产品。产品历时半年多的打磨,2015 年 1 月 16 日,钉钉 1.0 版本正式上线,一个 to B 端的风口自此打开,钉钉赢得了市场口碑,开始快速成长。

在后面总结成功的方法论时,陈航认为,钉钉产品成功的法宝就是共创,在企业级市场,做产品最大的忌讳是 " 是躲在办公室里‘ YY ’ "。在一开始,钉钉其实只为一家中小企业服务,解决了他们明确得使用场景诉求,搞定了一个企业的诉求,产品至少能够在一个企业持续 wok,后面再针对类似企业实现产品的通用化和商业化,所以我们很容易在一开局就切到企业的痛点。

2)飞书最开始是为解决字节内问题部而孵化产品工具

字节跳动用过 slack、用过钉钉,但是始终与字节的工程师文化及高速成长的速度不匹配,于是伴随着一鸣 " 像打造公司一样打造产品 " 的理念开始内部孵化飞书;不断解决内部的各种问题,将内部各种先进的理念融入到飞书中,致力于打造出这个世纪最高效的企业生产率工具;内部一度流传,字节员工离职后最舍不得的就是飞书,在内部获得非常高的评价后开始逐步对外商业化。

2. B 端产品 MVP 核心场景明确,快速生产容易

前面说到 B 端产品解决问题的意图明确,价值也易论证,所以启动起来相对比较容易;同时相比于需要做大量的用户研究和调研的 C 端 MVP 版本,B 端产品 MVP 版本,因为一开始用户和使用场景比较聚焦,只需要针对明确的用户场景做出不同版本的方案,与种子用户反复确定、细致沟通,几轮下来基本可以圈定出核心的 MVP 版本功能架构,然后快速生产,通常第一个版本 1-2 个月内完成开发,交付用户使用,快速解决用户当前问题。

但是我们在规划产品时需要给后面无限衍生拓展做好可拓展计划,很有可能和以后成熟的产品相比,你今天只是种了一棵小树,而成熟的产品是一片森林循环系统。另外我们要一开始就重视用户,C 端我们还能瞬间把自己切换到小白用户视角,B 端如果不是深耕行业的专家或者是在业务侧沉淀了很久,是很难站在用户既有的视觉高度和实际的业务场景思考问题的。所以 MVP 版本和用户共创非常重要,我们需要深入到业务层,流畅的解决用户的几个核心点,让用户对产品价值的感知有一定的度,让业务侧喜欢上产品。

总之,如果简单做一个满足种子用户的 MVP 版本,解决用户的问题,是比较容易的;但是如果希望做一个破圈的产品,我们需要在产品构架和对业务深入理解上下功夫。

3. B 端产品的备孕妈妈,容易找到第一个金主爸爸一起孕育

如果产品是针对大 B 或者大 G 业务,那么创始人往往能够凭借关系,搞定几个大客户,完成产品的第一轮天使轮融资,比如晓多科技刚刚开始创立时就是合伙人接了几个大单,服务了几个大客户,然后将核心产品做出来,然后不断打磨完善。特别是政府项目就更是如此,公司先通过各种渠道拿到项目,然后再根据项目要求打造通用型的产品,基于定制化的产品,拿着金主爸爸的钱,逐步将产品通用化。

还有一些大企业内部会孵化一些给自己使用的产品,其实也是先拿到了公司的第一笔投资开始进行产品生产,所以这项业务能够在开工前拿到第一笔启动资金,找到一个金主爸爸和妈妈一起备孕。

相对来说,小 B 端产品开局比较难一些,因为让小企业花钱呢不太容易,小 B 端产品也需要和 C 端产品一样,先要抓住用户痛点,养用户,慢慢再推出一些超值的服务进行产品的商业化探索。钉钉、企业微信、飞书这三个产品的思路是这样,做成一个大的平台,如何再玩流量思维。也有如蓝湖、墨刀这类产品先前通过免费吸引了小 B 端用户,然后再慢慢进行商业化尝试,目前活得也不错。

二、B 端产品幼童期:长大难,侏儒多

我们发现市场上有很多专门为 B 端提供各种解决方案的集成商,他们为各种类型的企业提供软件开发服务,还有一些大厂比如 BAT,他们为了企业发展在内部其中专门有研发团队研发各种各样的 B 端产品,那这些产品为啥都没能够走出最开始服务的种子用户,在市场上获得成功呢?我认为 B 端产品长大不易,最直接的需要跨越下面这两道门槛:

1. 产品定制化严重,长大需要跨越通用性

B 端产品一开始只是为了适应某一类型企业、某个聚焦场景进行设计开发,快速解决某类客户某几个场景的需求,这个时期是 B 端产品的幼童时期,给某几个企业去使用没有问题;但是想要更进一步将产品开放给更多企业去使用时,就将面临着有些功能 A 企业需要,但是 B 企业觉得看着碍眼没有什么用,还容易产生误操作,而 B 需要解决的场景,产品里面又没有,但是 A 企业压根不需要。这个时候就要将场景更加抽象化,提供更加底层的能力建设,使得产品能够满足各种复杂场景下的情况。

面临各种不同企业的诉求,通常我们能做的就是将某些功能模块进行抽象,进行组件化,让企业通过简单的拖拉拽即可实现不同企业的诉求,例如审批产品,为了适应出差、报销、请假等各种场景下的申请页面填写诉求,我们不是针对每个场景去开发一个申请页面,而是将表单里面的内容抽象为一个个控件,比如单行文本、时间选择控件、单选控件等,用户就算是有 100 个场景也能够轻松通过拖拉拽的方式快速配置出来,这种就是从应用层面提供产品强大的配置能力,以最低成本满足各种类型用户的诉求。

如果再往底层拓展,为了满足一些更大企业对于表单的变态诉求,我们可以将表单组件的定制功能开放出去,企业可以直接基于平台的能力开发自己的组件,对局部功能进行改造和定制,这就到了 PAAS 层的开放,特别对于一些有开发实力的大企业,这种能力也是必不可少的。另外我们还可以将表单中的数据开放通过 API 接口开放给其他系统去调用,比如在审批系统中发起一个请假,在考勤系统中就对应的当天没有打卡就不算缺勤,这就到了数据层面的开放。

当然,要让 B 端产品从最开始解决一个小场景问题,要做到适配各种场景的通用配置、PAAS 层、数据层开放,需要投入的人力物力财力是远超 MVP 版本的, 这就是很多 B 端产品到 MVP 版本就终止生长,一直修修补补当做童工使用的原因。

2. 产品交易周期长,长大需要跨越商业化

上面第一点我们知道了 B 端产品跨越通用性需要付出巨大的代价,如果代价后面能够有极高的收益,相信还是会有企业趋之如骛的,但是 B 端产品的商业化往往周期很长,收回成本需要一个跨越一个比较长的周期,这也是很多企业让 B 端产品止步于儿童期的原因。

之前我们在【B 端用户】中说到,影响 B 端产品购买决策的人很多,决策的流程复杂,所以 B 端产品的商业化周期被拉长。大 B 用户有付费愿意,但是大 B 对产品的复杂性和通用性要求很高,就算产品能够满足需要,也要经历非常漫长的采购周期,少则几个月、多个半年到 1 年以上都有,期间客户维护的成本很高,很多企业维护客户的成本远远大于投入研发的成本,所以国内很多 B 端产品根本没有足够经费来提升产品竞争力,钱都花在了客户维护上,通过养一批大客户销售维护关系成交产品,短期内成果显著,但是慢慢的会发现产品的竞争力会逐步下降。小 B 产品更难一筹,小 B 用户除非必要,不然总习惯于白嫖,目前绝大部分针对小 B 的产品都是亏损状态,挣扎在活命的边缘。

总结一下,我们今天讲述了 B 端产品生命周期中的孕育期和幼童期,孕育期和生产期因为用户和场景聚焦所以比较容易,能够快速解决一小部分用户的问题,在儿童时期做起了童工。但是要进一步跨越儿童期,成长到青少年期就比较困难,需要跨越产品的通用性和商业化这两道门槛。接下来我们还会仔细分析 B 端产品成长为青少年和成熟后的进一步情况,喜欢的同学可以继续关注起来。

作者:ToB 一线,微信公众号:ToB 一线

本文由 @ToB 一线 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

以上内容由"人人都是产品经理"上传发布 查看原文
qyangluo
留言与评论(共有 0 条评论)
昵称:
匿名发表 登录账号
验证码: